Building a Smart Recommender System Across LINE Services
2019/11/20 18:11
Namikawa Jun
フェローというポジション
役員だかエンジニアなのかわからない
ふらふらしながらいろんなサービスにMLのシステムを作っている
背景
LINEは中心のアプリをファミリーサービスが取り巻いている
ファミリーサービスの中に大量コンテンツを持っているものも少なくない
必要な情報を届ける必要がある
特定サービスに情報が追加されても気がつくとことが難しい
字間が立つと意味がない情報はなおさら
サービスxコンテンツで横断した推薦をシてほしいということになる
Smalt Channel
最初は天気
漫画、占い、ニュース、スタンプ
どうやって届ければいいのか？
しくみ
各コンテンツを引っ張ってきてパーソナライズ
原理的には各サービスがパーソナライズするのがいい
コンテンツを集約して、最も望まれるコンテンツを選ぶ必要がある
中央の推薦システムの話をする
Smart Channelの歴史
横軸字間、縦がimpression（表示回数）、score（緑色がクリックとxの比率）
高ければ高いほどユーザからpositive
2019年6月から上がっている2倍程度（2.00ぐらい）
この間に何をしたのかを紹介する
制約条件
各サービスのすでにあるシステムとの連携
スケーラビリティ
cold start problem
すでにあるレコメンドシステム
ニュース
スタンプ
など
いろんな手法、いろんな目的で使われている
最初に考えるべきだったこと
レコメンド資産をすべて無視するのか、利用できるところは利用するのか？
最近stat
500M imp/day
100M DAU
60K+ contents/day
Only New Content Has Value
あそこに出すのは、字間が立つと価値を失う情報じゃないと意味がない
なぜ？
推薦システム側から見ると難しい（Cold start probrem）
どのようなシステムをつcったのか？
<<アーキテクチャの図>>
各サービスをそのまま採用することにした！
各推薦システムから上位kを中央キャッシュ（Candidates）にぶちこむ
LINE Appからリクエストが来たら
RankerがUserIDをCandidates(Recommended Items)からITemsを引く
Rankerが1つ選んでitemをアプリに返す
ユーザのアクションをイベントとして発行してTrainerに取り込む
Trainerがモデルパラメータを生成して、Rankerに送る
以後、各コンポーネントの説明
Ranker
表示可能なアイテム
リクエストの度に実行
Rankerはスコアの大きなものを
contextual banditsを使ってる
予測が正しくないケースが結構ある
しかしデータが
新しいデータを出す＆データを取得すrを２つを同時にやる
このバランスをとるためにbanditsをつかっている
予測モデル
<<モデルの図>>
Bayesian Factorization Machine
FMとは
入力の特徴量をの相互作用を計算できる
年齢と性別のANDを表現する
それをbandydでつかえるようにしたのが
特徴量は大きく3つ
ユーザー x item
あるユーザがコンテンツを好き化どうかが詳細にパーソナライズできる
User Features
Gender, Ages
Other Features
Timestamp
目的関数
Imp 0.5
Click 1.0
Mute 0.0
どう学習しているのか
<<構成図
主役はParameter Server
Trainer
規模的にMLのサービスは並列化が必須
複数ノード、複数プロセス
バラバラに学習してどっかでまとめる必要がある
それがParameter Server
まとめる部分の処理をParameter Serverが担っている
差分をParameterとマージしてパラメータをTrainerに返す
RankerもParameter Serverに問い合わせる
Asynchronous Distoributed Online Learning
2つのTrainerがある例
どういうシチュエーションか？
Trainer !がパラメータを受け取って学習してParamete serverに差分を送ってまたパラメータをもらう
Bは学習が進む速さが早くて、何度も差分を送っている
原因は様々
学習結果を送った頃にはTrainer Aのデータはもう意味ない
同期型でうまくいく場合は同期側のほうがよく学習できる
事前にどういうデータが度のモデルに到達するか読めない
なぜか？banditによってどのモデルが提供さられるかかわるから
よって非同期側で学習する必要がある
Trainer Aのデータをいい感じに
原則パラメーター
パラメータサーバが現在持ってるデータと、パラメータサーバの受け取った佐賀大きいほど、香辛料を小さくする
差分が古いので学習が変な方向にいくかもしれないので、量を減らして確率を減らす
Backtrack
ちょっと戻す
Trainer Aが学習したシチュエーションに近づけてあげる
でも原則もBacktrackも学習を遅くしてしまう
エンジニアリング的な手法でLBをうまく組んで、データはなるべく同じプロセスに行くとか、並列化をなるべくしないようにする仕組みをつくる。だめならアルゴリズムでやる
Storage for Parameters
ここききとれてないkadoyau.icon
ユーザの読み書きは直接読んでる
サイズが大きくてinline cacheでもてない
処理が偏る
ユーザーレベリングは同時に複数ノードで計算されないし、レアだから無視できる
スループットと学習の天秤
Platform for Data Analysys
モデルをチューニングするために分析やテストは欠かせない
データ解析を非常に重視している
どういう指標を重視するか？
何を持ってよいというのかわからないとチューニングできない
数理的に定義する必要がある
クリックと津ボタンのscoreという指標をしている
どのコンテンツが好き？というアンケートと、設定したスコアとアンケートにはよい相関があった
少なくともCTRとかよりは全然高い
計算がすごい楽
字間安定性が高い
どういうことなの？
Primary Performance Metric
ctr, xctrは新しいコンテンツをリリースしたりすると、ピークが立って、減衰する
見慣れないのでクリックしたりする
だんだんクリックもバツボタンもしなくなる（と考えている）
この当たりの値を見ても役に立たない
「物珍しいもの」を表示すればいいという話になってしまう
ダッシュボード
日々見てる
コンテンツが多数あるので、たまたまあるコンテンツで以上が出たかはわからない
異常検知して取りこぼしはSlackに通知が来る
Offline Test
Offlite Test
システムなくてもできて低コストで実験できていい
ABテスト
システムがある前提
ログをHadoopクラスタにおいとく
かんたんにオフラインテストでモデルを評価するような仕組みを作っている
bandid algorithmとか
聞き逃したkadoyau.icon
いろんなサービスがテストをシている
SmarchCHもここでテストしてる
実験
実際にABテストをやってみた
改善幅が大きかったつを紹介
モデルを切り替えた
LinUCB to Bayesian FM
線形のモデル
並列計算がめちゃくちゃ楽
単純和を取ればいいから
Bayesian FMしたら
ctr +4.8 xCTR -1.0 Score +5.8 -> 面倒だけどやった価値があった
Incorporate Images in Banner
UI変えただけ
画像ちっちゃいので効果あるの？と議論になった
画像ないしクロッピングする仕組み追加実装
CTR +56% CTR +35% +16% -> Score
「個人的には結構辛いなって結果」
User and Item Embeddings
<<図
各サービスのレコメンデーションは個人化されているが、さらに特徴量追加したらどうなるか
CTR +5.1% xCTR -16.2% Score +25.3% ->すごいうまくいった
Future
現状は各サービスのコンテンツを吸い出している一方通行のシステム
最適化をしようとすると、カップリングして最適化するのがいい
各サービス基盤のシステム自体を頭囲移させる方向で動いている
データ基盤・クラスタの頭囲うつ
GPUs on k8sを作ってみんな同じ環境では知らせる